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1.0  INTRODUCTION 


MITRE  is  currently  supporting  the  Electronic  System  Division  of 
the  Air  Force  in  the  area  of  digital  avionics.  One  aspect  of  this 
work  has  been  a continuing  critical  evaluation  of  MIL-STD-1553 
(USAF),  a document  that  has  recently  been  issued  to  standardize  the 
characteristics  of  time  division  multiplex  data  buses  for  use  in 
aircraft.  Much  of  the  earlier  comment  on  this  standard  was 
qualitative  in  nature  and  based  primarily  on  heuristic 
considerations.  However,  sufficient  progress  has  now  been  made, 
both  in  physically  implementing  a "standard"  bus,  see  Figure  1,  and 
in  the  performance  of  supplementary  calculations,  to  warrant  a 
somewhat  more  detailed  and  quantitative  evaluation  of  some  of  its 
requirements.  The  topics  covered  in  this  report  fall,  loosely, 
within  the  area  of  information  flow  over  an  avionics  bus  network, 
and  have  been  selected  because  they  obtruded  into  the  design  of 
MITRE's  experimental  system.  For  the  latter,  it  was  acceptable  to 
make  arbitrary  decisions  so  that  the  work  could  proceed  at  a rapid 
pace.  However,  when  finalizing  a standard  for  an  operational 
system,  a more  systematic  approach  is  necessary,  since  the 
ramifications  of  any  decision  may  be  very  significant.  This  report 
contains  a brief  account  of  some  problems  that  were  encountered,  and 
that  deserve  further  attention  by  the  designer  of  a "standard"  bus 
netwo  rk* 

The  material  is  treated  under  three  main  headings.  Background, 
covered  in  Section  2.0,  abstracts  pertinent  portions  of  MIL-STD-1553 
(USAF),  and  where  appropriate,  discusses  them  in  relation  to  the  MUX 
bus  network. 

Section  3*0,  Specific  Constraints,  contains  the  main  content  of 
the  report.  It  examines  some  elementary  data  handling  constraints 
that  are  implicit  in  the  standard  or  arise  from  its  ambiguities  and 
omissions.  The  particular  topics  covered  are: 

• Bus  capacity,  Section  3*1 

• A time  constraint  on  message  handling,  Section  3*2 

• Subaddresses  and  Data  Word  accessibility,  Section  3*3 

• Temporal  aspects  of  signal  information  transfer  by  an 

avionics  bus,  Section  3*4. 

Section  4.0,  Summary  and  Conclusions,  briefly  summarizes  the 
content  of  the  report,  and  indicates  the  potential  problem  that  is 
presented  in  the  quest  for  the  "standard"  bus. 
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2.0  BACKGROUND 


A number  of  factors  referred  to  in  the  following  sections,  and 
used  in  the  calculations,  are  contained  explicitly  and/or  implicitly 
in  MIL-STD-1553  (USAF),  For  convenience,  the  pertinent  paragraphs 
are  abstracted  below  with  explanatory  notes  where  this  is  considered 
desirable. 

2 . 1 Data  Rate  and  Bus  Capacity 

Section  4, 2. 3*3  of  MIL-STD-1553  (USAF),  30  August  1973,  states, 
"Data  Rate.  The  data  transmission  rate  on  the  bus  shall  be  1.0 
megabit  per  second  with..." 

This  is  an  explicit  statement  concerning  the  rate  at  which  the 
bits  within  a message  are  placed  on  the  line,  and  when  considered  in 
conjunction  with  other  sections  of  the  standard,  leaves  no  doubt  as 
to  the  intent  of  the  requirement. 

The  absence  of  any  explicit  mention  of  bus  capacity  in  the 
standard,  either  in  Section  3*0  on  definitions  or  in  Section  4.0 
giving  requirements,  necessitates  some  measure  of  interpretation. 

It  should  perhaps  be  stated  at  the  outset  of  the  following 
discussion  that  this  author  thought  the  intent  of  the  standard  was 
quite  clear!  However,  any  ambiguity  in  this  area  could  result  in 
serious  incompatibilities,  both  within  and  between  bus  systems;  thus 
the  subject  warrants  further  discussion.  The  point  of  contention  is 
whether  the  standard  implicitly  places  a requirement  on  the  bus 
capacity,  or  if  this  parameter  is  left  under  the  control  of  the  bus 
designer. 

When  binary  waveforms  are  used  on  a line,  it  is  fairly  common 
usage,  although  perhaps  incorrectly  so,  to  identify  the  data  rate  of 
the  transmission  with  the  capacity  of  the  line.  Thus  in  the  present 
case,  the  requirement  that  the  bus  should  operate  at  a data  rate  of 
1 megabit  per  second  implies  that  the  system  should  be  capable  of 
placing  one  million  bits  on  the  line  each  second.  Thus,  a 
"standard"  bus  system  would  have  the  capability  of  operating  at  a 
duty  cycle  of  100  percent.  Whether  any  particular  application  of 
the  multiplex  bus  on  board  an  aircraft  requires  operation  at  a high 
duty  cycle  is  a different,  but  relevant,  question.  This  point  was 
discussed  with  the  authors'  of  the  standard  when  it  was  originally 
issued,  and  there  was  general  agreement  on  the  above  interpretation. 
Indeed  any  different  understanding  leads  rapidly  to  a number  of 
conclusions  that  run  contrary  to  the  basic  tenets  of 
standardization,  and  would  negate  many  of  the  very  real  advantages 
to  be  gained  by  establishing  identity  of  critical  bus  parameters. 
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While  the  arguments  in  favor  of  specifying  a capacity  for  the 
bus  system  are  conclusive,  the  question  of  what  that  value  should  be 
is  somewhat  contentious.  Since  the  standard  was  originally  issued, 
considerable  work  has  been  done  on  various  aspects  of  its 
implementation,  and  some  of  the  implications  of  attempting  to 
operate  a bus  at  a high  duty  cycle,  using  the  message  formats 
defined  in  the  standard,  have  been  examined.  Some  quantitative 
results  arising  from  various  combinations  of  these  conditions  are 
given  in  Section  3.2. 

Before  leaving  this  topic,  one  other  point  should  be  discussed. 
Several  mission  oriented  studies  have  been  made  to  determine  the 
information  flow  on  the  bus  arising  from  servicing  various  avionics 
suites,  and  tne  resulting  data  processing  load  for  the  message 
handling  function.  Their  results  have  been  construed  to  indicate 
that  the  bus  will  be  so  under  utilized  that  the  questions  of  whether 
or  not  the  bus  can  be  operated  at  a high  duty  cycle,  and  whether  it 
is  used  efficiently,  are  academic  and  not  worth  consideration.  As 
to  the  first  point,  the  question  of  a high  duty  cycle  arises  from 
the  implicit  requirement  of  the  present  standard.  Perhaps  the 
figure  is  impracticably  large,  but  the  crucial  factor  is  that  some 
definite  requirement  for  the  "standard"  bus  must  be  given;  it  is 
necessary  to  avoid  incompatibilities  when  integrating  bus  subsystems 
into  a bus  network,  and  when  interfacing  different  "standard"  buses 
with  one  another.  As  to  the  other  point  of  operating  a bus 
ef ficiently--in  the  context  of  information  transfer — there  are 
various  design  constraints  that  significantly  reduce  the  capacity  of 
the  line  available  for  signal  transfer  between  units,  which  are  not 
immediately  apparent  to  a system  designer  reading  the  standard,  and 
warrant  further  consideration  before  reckless  use  is  made  of  this 
resource. 

2.2  Word  Characteristics 


Sections  4.2. 3.4  and  4, 2. 3. 5 of  MIL-STD-1553  (USAF),  30  August 
1973,  define  the  word  characteristics — size  and  format--that  can  be 
used  on  the  bus.  The  contents  of  these  sections  are  summarized 
diagrammatically  in  Figure  2. 

2,3  Message  Formats 

Section  4. 2, 3* 6 of  the  standard  describes  the  bus  protocol  that 
will  be  used  on  the  line;  the  content  is  summarized  in  Figure  3. 

It  is  the  message  and  word  formats,  shown  in  Figures  2 and  3, 
which  determine  the  "overhead"  that  is  incurred  with  each  transfer 
of  information  on  the  line.  Consequently,  they  establish  an  upper 
bound  on  the  fraction  of  the  nominal  capacity  of  the  bus  (1  Mbps), 
that  is  available  for  the  interchange  of  signals  between  source/sink 
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Figure  2 WORD  FORMATS 
MIL  -STD  -1553  (USAF) 


COMMAND 

COMPONENT  * RESPONSE  COMPONENT 


CO 

o 

cr 

o 

^ CD  CT 
UJ  -J 

^ cc 
w jh 

^>o 

< w<-> 


Q 


Q 


* 

<_) 


CO 

Q 

cr 

o 

£ 


< 

0 

<\J 

rO 

1 


cr  _j 

di 

02 

era: 

H UJ 
ZK 


\ 


z 

LlI 

z 

o 


CO 

z 

o 

CL 

CO 


o z 
z 
< z 

So 

o 


o 

* o 
00  H 
3 cr 
O UJ 

u 

t—  a 
z t- 
o z 
u o 


cr 

cr 

UJ 

CL 

</> 

z 

< 

cr 

»- 

co 

o 

cr 

o 

* 


O 2 

o 
ui  cr 
o u. 

z 

uj  o 

3 UJ 

o <r 
uj  cr 

tO  uj 
CL 

••  z 

I-  < 

z cr 
uj  I— 
z 
o 
a 
2 
O 


Sg 

o 


8S 

CL 

O -J 
cr 


uj  o 
3 k 

2- 

to  ^ 

..  2 
I-  O 

z cr 

UJ  L. 

z 

O 

CL 

2 

O 


2 

2 


(O 

z 

o 


CO 

o 

o 

o 

H 

o 

Z UJ 

< > 

< < 

Z? 

— 

2ho 

“ 2 

OK  UJ 

2cr 

o cr  cr 

a:  uj 

*o 

8 


Figure  3.  MESSAGE  FORMATS  ON  MULTIPLEX  BUS 


pairs  serviced  by  the  line.  These  constraints  on  the  information 
capacity  of  the  bus  are  discussed  in  Section  3*1* 

2.4  Suitability  of  Subsystem  Signals  to  Bus  Transfer 

Section  10.3  in  the  appendix  to  MIL-STD-1553  (USAF)  briefly 
discusses  the  suitability  of  various  classes  of  signals  to  transfer 
on  the  bus.  The  section  is  reproduced  in  its  entirety  below. 

,f  1 0 . 3 Multiplex  selection  criteria.  The  selection  of  candidate 
signals  for  multiplexing  is  a function  of  the  particular 
application  involved,  and  criteria  will  in  general  vary  from 
system  to  system.  Obviously  those  signals  which  have 
bandwidths  of  400  Hz  or  less  are  prime  candidates  for  inclusion 
on  the  bus.  It  is  also  obvious  that  video,  audio,  and  high 
speed  parallel  digital  signals  should  be  excluded.  The  area  of 
questionable  application  is  usually  between  400  Hz  and  3 KHz 
bandwidth.  The  transfer  of  these  signals  on  the  data  bus  will 
depend  heavily  upon  the  loading  of  the  bus  in  a particular 
application.  The  decision  must  be  based  on  projected  future 
bus  needs  as  well  as  the  current  loading.  Another  class  of 
signals  which  in  general  are  not  suitable  to  multiplexing  are 
those  which  can  be  typified  by  a low  rate  (over  a mission)  but 
possessing  a high  priority  or  urgency.  Examples  of  such 
signals  might  be  nuclear  event  detector  output  or  a missile 
launch  alarm  from  a warning  receiver.  Such  signals  are  usually 
better  left  hardwired,  but  they  may  be  accommodated  by  the 
multiplex  system  if  a direct  connection  to  the  bus  controller's 
interrupt  hardware  is  used  to  trigger  a software  action  in 
response  to  the  signal.11 

The  guidance  given  to  the  system  designer  on  this  topic  is  so 
general  that  bus  systems  developed  by  different  organizations — in 
consonance  with  the  standard — could  well  be  incompatible  as  to  the 
classes  of  information  they  could  handle.  There  is  no  doubt  that 
the  task  of  standardizing  the  signal  classes,  in  regard  to 
suitability  for  bus  transfer,  would  be  substantial;  however,  unless 
more  definitive  criteria  are  given,  and  the  range  of  uncontrolled 
variability  reduced,  inter-bus  compatibility  will  not  be  ensured. 
Further  discussion  of  this  topic  is  given  in  Section  3*4. 
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3.0  SOME  SPECIFIC  CONSTRAINTS  ON  INFORMATION  FLOW 


Prior  to  the  generation  of  MIL-STD-1553  (USAF),  which  governs 
the  standardization  of  avionics  TDM  data  buses,  there  was  no 
guidance  as  to  a preferred  network  configuration,  operational 
concept,  or  message  format.  As  a consequence,  different  data  buses 
intended  for  use  in  the  same  vehicle  were  not  readily  able  to 
communicate  with  one  another.  The  issuance  of  MIL-STD-1553  (USAF) 
was  a major  step  towards  avoiding  such  problems  in  the  future,  and 
is  certain  to  contribute  significantly  towards  the  goal  of 
compatibility.  However,  the  development  of  an  all  encompassing 
standard  for  a system  as  complex  as  an  avionics  bus  network  is  a 
virtual  impossibility,  and  it  can  only  be  hoped  that  any 
shortcomings  that  exist  are  relatively  inconsequential.  In  the  year 
fiscal  75  MITRE  has  used  the  standard  as  the  basis  for  the  design  of 
an  experimental  bus,  thus  there  has  been  need  to  examine  its 
contents  in  some  detail.  In  configuring  the  message  control 
processing,  various  questions  arose  concerning  the  information  flow 
on  the  bus,  and  unambiguous  answers  could  not  be  found  in  the 
standard.  The  uncertainties  that  remained,  and  some  consequences 
that  derived  therefrom,  would  permit  the  development  of  incompatible 
"standard"  buses,  and  thus  seemed  worthy  of  further  consideration  by 
the  network  designer.  Four  of  these  areas  are  discussed  below: 

• Bus  capacity,  Section  3*1 

• A time  constraint  on  message  handling,  Section  3*2 

• Subaddresses  and  Data  Word  accessibility,  Section  3*3 

• Temporal  aspects  of  signal  information  transfer  by  an 

avionics  bus,  Section  3»^* 

3. 1 Bus  Capacity 

Following  the  discussion  of  Section  2.1,  it  will  be  assumed 
that  the  intent  of  MIL-STD-1553  (USAF)  is  that  the  avionics  TDM  bus, 
with  its  associated  remote  terminal  units,  should  have  a nominal 
capacity  of  1 Megabit,  i.e.  be  capable  of  operating  at  a data  rate 
of  1 Mbps  at  a 100  percent  duty  cycle.  While  this  requirement  is, 
in  itself,  of  some  significance,  a more  useful  parameter  for  the 
system  designer--particularly  since  the  line  must  operate  with  the 
prescribed  protocol--is  the  capacity  in  terms  of  signal  information 
bits. 


It  is  convenient  for  the  present  purpose  to  consider  the 
overall  system  capacity  of  1 Mbps  as  consisting  of  two  classes  of 
information.  One  of  these  is  the  "applications",  or  signal, 
information  which  it  is  the  function  of  the  bus  network  to  transfer 
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between  the  various  source/sink  pairs.  The  other  is  the  "overhead" 
information,  which  is  used  to  effect  the  Applications11  information 
transfer,  and  is  a by-product  of  the  line  protocol  defined  in  the 
MUX  bus  standard.  Since  all  signal  information  transfer  of 
necessity  incurs  the  transfer  of  overhead  information,  the  capacity 
of  the  bus  in  terms  of  the  former  is  less  than  1 Mbps,  and  in  some 
circumstances  very  significantly  so. 

When  operating  the  avionics  bus  according  to  the  prescribed 
discipline,  the  fractional  percentage  of  the  overall  data 
transferred  that  falls  within  the  category  of  overhead  is  a strong 
function  of  the  message  lengths  employed.  For  example,  if  a 
command/response  sequence  executes  a single  Data  Word  (DW)  transfer 
from  a remote  terminal  (RT)  to  the  controller  (CTRL),  the  message 
sequence  consists  of  a Command  Word  (CW)  from  CTRL  to  RT,  a 2-5 
microsecond  interval,  followed  by  a Status  Word  (SW),  a contiguous 
DW  containing  16  information  bits  from  RT  to  CTRL,  and  a 2-5 
microsecond  gap;  resulting  in  a fractional  overhead  of  3/4  (~7 5% ) . 
Alternatively,  if  the  requirement  was  to  transfer  32  Data  Words,  the 
Status  Word  would  be  followed  by  32  contiguous  DW,  yielding  an 
overhead  ratio  of  2 5% . Extrapolating  these  considerations  to  an 
operational  system,  the  fractional  "applications"  capacity  available 
to  the  system  designer  will  be  a function  of  the  message  sequence 
mix  necessary  to  effect  the  necessary  signal  information  transfers. 
Further,  as  the  message  mix  is  changed  in  response  to  mission 
contingencies,  so  will  the  available  applications  capacity.  A 
quantitative  investigation  of  these  factors  is  better  left  until  the 
conditions  are  further  constrained,  and  a practical  message  mix 
formulated.  However,  an  estimate  of  the  decrease  in  capacity  due  to 
overhead  can  be  obtained  from  computations  based  on  a less  complex 
model: 

(a)  Bus  is  loaded--including  inter-message  and  component 
gaps--at  1 Mbps. 

(b)  All  message  sequences  are  of  same  type,  e.g.  all  remote 
terminal  to  controller,  etc. 

(c)  All  messages  contain  same  number  of  Data  Words. 

Using  these  simplifications,  curves  of  available  capacity 
versus  number  of  Data  Words/message  have  been  generated,  with 
message  type,  and  intercomponent/message  gap,  as  parameters,  see 
Figure  4,  A sample  calculation  is  given  in  Appendix  1. 

It  should  be  noted  that  the  "available  capacity"  represented  in 
Figure  4 is  the  maximum  bus  capacity  available  for  the  transfer  of 
signal  information  between  source/sink  pairs.  Further  constraints 
which  will  not,  in  general,  permit  this  capacity  to  be  achieved  in 
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practice,  arise  from  the  details  of  the  interchange  of  signal 
information  between  the  user  equipments  that  the  bus  is  required  to 
service.  In  the  example  given  above  it  was  tacitly  assumed  that  a 
Data  Word  contained  16  bits  of  signal  information  to  be  transferred 
from  source  to  sink.  However,  it  is  quite  probable  that  the  number 
of  signal  bits  to  be  transferred  between  any  given  pair  of  bus  users 
cannot  readily  be  subdivided  into  sixteen  bit  blocks,  thus  requiring 
some  additional  overhead  bits  be  appended  to  complete  the  partially 
filled  DWs.  The  one  Data  Word  transfer  of  the  previous  example 
which  gave  an  available  signal  capacity  of  25  percent  is  an  extreme 
case.  If  the  only  signal  information  to  be  transferred  in  this 
message  was  a discrete--a  switch  position,  say — then  fifteen  bits  of 
the  sixteen  in  the  DW  would  be  classed  as  overhead  and  the 
fractional  signal  capacity  would  decrease  to  ^2  percent. 
(Alternatively,  the  fractional  overhead  capacity  would  increase  to 
percent.)  If  an  estimate  is  made  of  the  average  fractional 
utilization  of  a Data  Word,  i.e.  (average  number  of  signal  bits  per 
DW)/  16),  the  effects  of  this  partial  DW  usage  can  be  obtained  from 
its  fractional  value  multiplied  by  the  fractional  available  signal 
capacity  shown  in  Figure  4. 

The  foregoing  is  a relatively  simplistic  assessment  of  the 
influence  of  the  line  discipline,  defined  in  MIL-STD-1553  (USAF),  on 
the  signal  capacity — in  contrast  to  the  nominal  capacity — of  the  TDM 
bus.  The  problem  will  be  touched  upon  again  when  the  topic  of  word 
and  message  packing  is  discussed  in  Section  3*2. 1 . 

3.2  A Time  Constraint  on  Message  Handling 

It  has  already  been  pointed  out  in  Section  2.0,  that  the  USAF 
goal  of  developing  a "standard"  avionics  bus  according  to  the 
requirements  of  MIL-STD-1553  (USAF)  implies  that  the  bus  components 
be  capable  of  operating  at  a 100  percent  duty  cycle,  even  if  a 
particular  application  does  not  make  these  demands.  With  this  fact 
in  mind,  some  calculations  were  made  to  determine  the  time  available 
for  the  basic  control  operations  necessary  to  fulfill  the  primary 
bus  functions  of  collection,  transfer  and  distribution  of  data 
between  source/sink  pairs,  while  the  system  is  under  maximum  load, 
i.e.  operating  at  100  percent  duty  cycle. 

It  should  be  noted  that  for  the  present  purpose  the  control 
function  has  been  narrowly  defined.  In  essence  the  network  is  being 
treated  as  a transfer  device,  with  attention  being  confined  to 
moving  the  data  between  source/sink  pairs  without  consideration  as 
to  its  content  and  any  prior  or  subsequent  processing  that  this 
might  require.  It  is  further  assumed  that  "no  error"  conditions 
exist;  the  purpose  being  to  avoid — in  this  report--the  complexities 
of  network  reconfiguration  and  similar  types  of  operation,  which 
would  certainly  fall  within  the  scope  of  any  but  the  most 
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restrictive  of  definitions  of  the  bus  control  function.  The  primary 
reasons  for  adopting  this  definition  of  bus  control  are  twofold; 
first,  it  has  been  the  aim  to  obtain  an  appreciation  for  the  problem 
based  on  relatively  elementary  calculations;  second,  the 
"peripheral"  control  activities,  e,g,  network  reconfiguration, 
status  monitoring,  etc.,  are  not  treated  in  MIL-STD- 1553  (USAF),  and 
thus  their  scope,  and  method  of  implementation,  are  more  under  the 
control  of  the  system  designer  than  are  the  mandatory  capabilities 
defined  in  the  standard. 

The  timing  constraint  considered  in  this  section  is  that 
arising  from  the  message  handling  capability  of  the  bus  system. 

This  parameter  is  a derivative  of  the  data  rate  on  the  line,  the  bus 
discipline  and  bus  capacity;  all  of  which  are  explicitly  or 
implicitly  contained  in  the  standard.  In  the  present  case  each  of 
the  requirements,  when  treated  separately,  appears  to  be  relatively 
innocuous;  however,  when  considered  together,  the  resulting 
requirement  on  the  message  handling  capacity  is  quite  severe.  For 
example,  the  data  rate  on  the  line  is  to  be  at  1 Mbps:  this  is 

performance  well  within  the  present  state-of-the-art,  the  passenger 
service  system  on  the  Boeing  747 — which  uses  a TDM  bus--operates  at 
a data  rate  of  6 Mbps* 

The  bus  discipline  described  in  the  standard  permits  a range  of 
message  structures.  These  are  shown  diagrammatically  in  Figure  3> 
and  their  respective  durations  in  time  are  given  in  Table  I,  The 
latter  conversion  was  made  via  the  data  rate,  word  lengths  in  bits, 
synchronization  and  intermessage/component  gap  characteristics,  all 
contained  in  the  standard.  Coupling  the  requirement  for  operation 
at  100  percent  duty  cycle  with  the  message  durations  given  in  Table 
I,  the  curves  of  Figure  5 were  generated,  showing  the  variables 
(number  of  messages  per  second)  versus  (number  of  Data  Words  per 
message),  with  message  type  and  "gap"  times  as  parameters.  It  can 
be  seen  that  the  message  handling  capacity--at  a 100  percent  duty 
cycle — spans  a range  of  approximately  1 . 5K  to  15.5K  messages  per 
second,  dependent  upon  the  number  of  Data  Words  in  each  message. 
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TABLE  I 


Duration  in  Time  of  Bus  Message  Modes 


Message 

# Data 

//Overhead 

Intercomponent 

Intermessage 

Minimum 

Mode 

Words 

Words 

Gap 

Gap 

Duration 

(micro- 

secs) 

Remote  (Min) 
Termi nal 

1 

2 

1 

1 

64 

to  (Max) 

Controller 

Controller 

32 

2 

1 

1 

690 

to  (Min) 

1 

2 

1 

1 

64 

Remote  (Max) 
Terminal 

32 

2 

2 

1 

690 

Remote  (Min) 
Terminal  to 

1 

4 

2 

1 

106 

Remote  (Max) 
Terminal 

32 

4 

2 

1 

735 
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Some  consideration  of  the  control  function  in  the  context  of 
the  data  processing  demands  imposed  on  the  controller  will  indicate 
that  the  message  is  the  basic  processing  unit.  The  message  rate  and 
capacity,  coupled  with  the  data  processing  requirements  per  message, 
are  of  more  significance  to  the  controller  than  the  line  data  rate. 
The  bus  activities  associated  with  each  message  unit  are  the 
fundamental  steps  of  collection,  transfer  and  distribution  of  data, 
and  when  the  system  is  operating  at  100  percent  duty  cycle,  the 
processing  in  the  controller  arising  from  each  of  these  operations 
must  be  performed,  effectively,  in  real  time.  If  the  maximum 
message  handling  capacity  is  considered,  i.e.  one  Data  Word 
transfers  between  RT  and  CTRL,  Table  I indicates  that  the  available 
time  for  processing  the  message  is  approximately  64  microseconds; 
alternatively,  the  minimum  handling  capacity,  i.e.  32  DW  transfers, 
permits  an  interval  of  690  microseconds.  Which  of  these  is  the  more 
restrictive  will  depend  on  how  the  processing  varies  with  message 
length.  For  example,  each  additional  DW  in  a message  has  a 20 
microsecond  duration  on  the  bus,  and  thus  provides  an  increase  of 
that  amount  for  message  handling.  If  the  additional  processing  time 
incurred  by  the  extra  DW  is  less  than  20  microseconds,  there  will  be 
a net  gain;  if  the  incremental  processing  time  per  word  is  greater 
than  20  microseconds,  there  will  be  a net  loss.  Since  the 
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resolution  of  this  point  involves  more  detailed  investigation  than 
is  warranted  in  this  report,  attention  will  be  confined  to  a one  DW 
command/response  message  sequence  and  its  associated  available 
processing  time  of  64  microseconds.  In  terms  of  a typical  general 
purpose  digital  computer  (GPDC),  that  might  be  used  as  a bus 
controller,  this  interval  is  equivalent  to  about  35  instructions  of 
the  mix  used  in  message  handling. 

To  obtain  an  estimate  for  the  number  of  instructions  that  might 
be  required  if  the  control  processing  was  to  be  done  by  a GPDC, 
advantage  was  taken  of  the  work  that  is  currently  being  done  at 
MITRE  on  the  implementation  of  a rudimentary  bus  system  in 
accordance  with  MIL-STD-1553  (USAF) . The  bus  control  aspects  of 
this  work  have  been  outlined  in  two  previous  reports.  References 
2 and  3,  and  will  not  be  discussed  further  herein.  The  estimate  of 
time  and  number  of  instructions  for  a single  DW  message  sequence  given 
in  Figure  6 was  obtained  from  Reference  2.  The  numbers  indicate 
clearly  that  the  view  originally  put  forward  that  the  basic  bus 
control  function  could  be  absorbed  by  a GPDC  as  a negligible 
extension  to  its  other  functions  is  not  tenable  when  considered  in 
the  context  of  a "standard"  bus  which  must  have  the  capability  of 
operating  at  100  percent  duty  cycle.  It  is  these  considerations 
that  have  initiated  the  design  of  a more  sophisticated  hardwired 
unit  to  interface  the  GPDC  to  the  bus;  its  purpose  will  be  to  absorb 
the  majority  of  the  routine  control  functions  shown  in  Figure  6,  and 
thus  reduce  the  load  on  the  processor. 

The  time  constraint  outlined  above  becomes  apparent  even  when  the 
scope  of  the  control  function  is  confined  to  its  bare  essentials.  Any 
broadening  of  its  scope  to  include  other  control  activities — partic- 
ularly if  necessitating  additional  processing  in  the  GPDC  on  each 
message  sequence,  can  only  compound  the  problem.  The  timing  constraint 
will  be  touched  upon  again  when  the  topic  of  word  and  message  packing 
is  discussed  in  the  next  section. 

3.2.1  The  Packing  of  Multiple  Signals  Into  a Data  Word 

One  aspect  of  the  message  handling  software  that  merits 
particular  attention  is  that  of  distributing  the  signals  contained 
in  the  received  Data  Words  to  the  appropriate  applications  routines 
within  the  bus  controller.  In  its  simplest  form  this  might  be 
thought  of  as  placing  an  incoming  Data  Word  into  a predetermined 
location  in  core  so  that  it  can  be  accessed  by  the  user  function  as 
required.  Analysis  of  various  equipments  has  shown  that  many 
signals  transferred  between  source-sink  pairs  serviced  by  the  bus 
can  be  represented  by  small  bit  fields,  and  the  dedication  of  a 
separate  Data  Word--which  potentially  has  16  information  bits — to 
each  signal  would  significantly  reduce  the  effective  information 
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Figure  6 EXPERIMENTAL  BUS  CONTROL  SOFTWARE  : BASIC  CYCLE 


capacity  of  the  system.  To  avoid  this  loss  of  capacity,  it  has  been 
suggested  that  several  signals  be  packed  into  a single  Data  Word. 
Thus,  the  information  density  of  the  word  would  be  increased,  and 
the  capacity  of  the  bus  be  more  efficiently  utilized*  However,  in 
the  context  of  the  message  handling  software,  a distinction  must  be 
made  between  the  case  of  n bits  of  a Data  Word  representing  a single 
signal  and  being  processed  as  an  entity  by  a single  applications 
routine,  and  that  of  the  n bits  being  comprised  of  several  signals 
each  destined  for  a separate  applications  routine.  The  difference 
lies  in  the  magnitude  of  the  unpacking  and  internal  distribution 
task.  To  clarify  the  point,  consider  a specific  example  as  it  might 
apply  to  the  experimental  TDM  bus.  Data  words  from  the  remote 
terminals  are  transferred  from  the  bus--a  shielded  twisted  pair--to 
the  core  of  the  bus  controller--a  PDP-9  general  purpose  digital 
computer — via  the  bus  control  interface  unit.  All  received  Data 
Words  in  an  incoming  message  are  stored  in  a common  buffer  in  core. 
Each  word  is  then  distributed  to  the  location  appropriate  for  access 
by  its  application  routine.  The  PDP-9  is  a single  address  machine, 
with  a memory  cycle  of  one  microsecond,  and  without  general  purpose 
registers.  The  transfer  of  a Data  Word  containing  a signal  from  the 
common  buffer  to  the  user  location  consists  of  a two  instruction 
load  and  store  sequence  requiring  four  memory  cycles.  If  the  Data 
Word  contained  four  signals  each  required  by  a different  user 
routine,  then  four  three-instruction  sequences--load,  mask,  and 
store--would  be  required  to  distribute  the  information,  using  24 
memory  cycles  in  all.  This  six-fold  increase  in  time  taken  by  the 
internal  distribution  of  the  information  arises  from  a relatively 
conservative  example  of  packing.  If  16  discretes  were  packed  into  a 
Data  Word,  the  increase  would  be  24  times.  Moreover,  in  some 
instances,  e.g.  if  the  packed  signals  were  represented  by  two  bit 
binary  numbers,  further  operations  would  be  necessary  to  present  the 
correct  magnitudes  to  the  applications  routines. 

This  example  illustrates  that  while  the  technique  of  word 
packing  increases  the  information  density  within  a Data  Word,  there 
is  an  accompanying  increase  in  the  time  required  per  Data  Word,  and 
hence  per  message,  to  unpack  and  distribute  the  information  to  the 
user  routines  within  the  bus  controller.  Comparison  of  the  time 
requirements  for  these  operations  with  the  execution  times  of  the 
other  components  of  the  basic  message  cycle  indicates  that  the 
unpacking  and  distribution  of  the  signals  within  the  bus  controller 
has  the  potential  of  being  the  most  time  consuming  phase  of  the 
message  handling  activities. 

Although  not  explicitly  mentioned  previously,  it  will  be 
apparent  that  there  are  analogous  considerations  in  regard  to 
execution  time  involved  in  the  collection  and  packing  of  signals 
into  the  Data  Words  within  the  bus  controller,  prior  to  transferring 
them  to  a remote  terminal.  These  steps  will  not  be  reviewed  in 
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detail;  however,  it  should  be  noted  that  they  constitute  an 
additional  significant  contribution  to  the  execution  time  of  the 
basic  message  handling  cycle. 

Another  consideration  related  to  word  packing  and  unpacking 
within  the  bus  controller  is  the  requirement  that  such  an  approach 
imposes  upon  the  remote  terminal.  This  technique  presupposes  a 
level  of  sophistication  in  the  processing  capability  of  the  remote 
terminal  sufficient  to  perform  corresponding  packing  and  unpacking 
activities.  The  time  constraints  are  not  as  restrictive  as  those  at 
the  bus  controller,  and  for  this  reason  a microprocessor  has  been 
suggested  for  the  task.  If  the  capability  of  present  day 
microprocessors  to  meet  these  requirements  is  questioned,  the 
argument  is  frequently  advanced  that  the  bus  controller  is  required 
to  perform  the  message  control  operations  associated  with  servicing 
32  remote  terminals,  whereas  the  microprocessor  is  dedicated  to  a 
single  terminal.  The  implication  is  that  although  present 
microprocessors  are  slower  than  conventional  computers,  the 
differential  is  not  so  great  as  to  warrant  the  question!  While  the 
description  of  the  relative  functions  of  the  bus  controller  and  the 
remote  terminal  processor  is  accurate,  it  should  be  recalled  that 
there  is  no  requirement  in  MIL-STD-1553  (USAF)  that  the  bus  network 
should  always  have  a large  number  of  terminals,  nor  that  they  be 
serviced  in  order.  If  a multiplex  bus  is  servicing  many  terminals, 
it  is  quite  likely  that  a given  remote  terminal  would  be  required  to 
participate  in  several  successive  bus  controller/subsystem 
information  transfers.  Although  a microprocessor  might  be  quite 
adequate  to  meet  the  average  processing  load,  its  ability  to  cope 
with  the  fluctuating  demand  is  not  so  apparent.  It  is  possible  that 
some  of  these  difficulties  could  be  met  by  careful  scheduling  of  the 
microprocessors  tasks.  However,  the  necessity  for  such 
sophistication  in  the  programming  of  the  remote  terminals  is  most 
undesirable. 

3 • 3 Subaddresses  and  Data  Word  Accessibility 

It  has  been  pointed  out  in  Section  3*1  that  the  available 
capacity  of  a "standard"  bus  for  the  transfer  of  user  data  between 
equipments  being  serviced  is  significantly  less  than  might  be 
supposed  by  the  use  of  a 1 Mbps  rate  on  the  line,  see  Figure  4. 
However,  these  curves  represent  upper  bounds  on  the  available 
information  capacity  which  cannot  readily  be  attained  in  an 
operational  system.  Many  factors  can  lead  to  this  shortfall.  A 
quantitative  evaluation  of  their  absolute,  and  relative, 
significance  would  be  sufficiently  complex — in  execution  rather  than 
concept--to  necessitate  a simulation  involving  alternative  bus 
architectures,  suites  of  avionics  equipments,  and  a range  of 
aircraft  missions.  Such  an  effort  does  not  fall  within  the  scope  of 
MITRE's  present  work  in  the  area  of  avionics  buses.  However,  an 
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heuristic  discussion  of  some  of  the  factors  arising  from  various 
constraints  in  MIL-STD-1553  (USAF)  which  may  lead  to  a de  facto 
reduction  is  in  order. 

3*3*1  Addressing  Memory  at  Remote  Terminals 

A conceptual  representation  of  the  distributed  memory,  i.e.  the 
storage  located  at  the  remote  terminals,  associated  with  a 
"standard"  bus  and  the  address  fields  for  referencing  it,  are  shown 
in  Figures  7 and  8. 

The  first  subdivision--to  the  level  of  a remote  terminal — is 
referenced  by  a five-bit  field  termed  the  MTU  address.  Its 
magnitude  provides  for  a potential  loading  of  32  uniquely 
addressable  remote  terminals  per  bus  system. 

The  second  subdivision  is  addressed  by  a single  bit  field--the 
transmit/receive  bit.  According  to  MIL-STD-1553  (USAF),  the  intent 
is  to  indicate  the  action  required  of  the  remote  terminal  (RT). 
However,  it  can  also  implicitly  reference  two  distinct  areas  of  the 
memory  within  the  RT;  one  dedicated  to  the  storage  of  incoming 
informa tion--when  the  RT  is  in  receive  mode;  the  other  confined  to 
the  buffering  of  the  outgoing  data--when  the  RT  is  in  the  transmit 
mode# 


The  third  level  of  addressing  consists  of  a five-bit  group,  the 
subaddress/mode  field.  For  the  purposes  of  the  present  discussion, 
the  only  significance  of  the  mode  designation  is  to  eliminate  one 
address  (00000)  of  the  32  possible  subaddresses,  each  of  which 
defines  a unique  block  of  storage  within  the  remote  terminal. 

The  fourth  subdivision  is  at  the  level  of  a word  block  within  a 
subaddress,  and  is  referenced  by  a five-bit  word  count  field#  Thus, 
the  maximum  number  of  storage  locations  associated  with  each 
subaddress — T/R  bit--pair  is  32* 

In  total  then,  there  is  a maximum  of  1984,  (2  x 31  x 32),  Data 
Word  locations  at  each  remote  terminal.  One  half--predetermined — of 
these  is  available  for  words  received  from  the  bus  controller  or 
other  remote  terminals,  and  the  remaining  half  is  for  words 
transmitted  to  those  units.  However,  due  to  the  nature  of  the  word 
count  parameter,  the  words  at  any  subaddress  are  not,  in  general, 
separately  accessible.  The  standard  does  not  define  a method  of 
identifying  the  required  word  within  a block,  so  for  convenience  of 
discussion  the  convention  shown  in  Figure  7 is  adopted;  it  consists 
of  consecutively  numbering  the  storage  locations  from  one  end#  Then 
if  the  bus  controller  requires  the  rth  DW  at  a given  subaddress,  it 
will  issue  a command  word  to  the  appropriate  remote  terminal 
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CONCEPTUAL  REPRESENTATION  OF  DISTRIBUTED  MEMORY 
ASSOCIATED  WITH  A STANDARD  BUS 


requesting  that  a block  of  (r+1)  Data  Words  be  transferred  to  the 
controller,  the  required  word  being  the  last--the  rth — in  the  block. 

The  constraint  of  transferring  a block  of  (r+1)  Data  Words  in 
order  to  access  the  rth  has  the  potential  to  markedly  decrease  the 
available  information  capacity  of  the  bus.  For  example,  if  the  bus 
controller  requires  a DW  in  the  fifteenth  location  of  a subaddress, 
then  a block  of  16  Data  Words  must  be  transferred.  The  useful 
information  capacity  of  the  message  interchange  would  be  only  6 
percent  of  that  assumed  in  the  available  capacity  curves  of  Figure 
4.  It  may  be  objected  that  a pessimistic  picture  is  being  presented 
by  selecting  the  fifteenth  word,  rather  than  the  third,  say;  the 
latter  would  give  a useful  information  capacity  of  25  percent  of 
that  assumed  in  Figure  4.  However,  examinations  of  these  curves 
indicate  that  the  upper  bounds  for  the  shorter  blocks  of  data  words 
are  significantly  lower  than  those  for  the  longer  blocks;  thus,  the 
net  result  is  still  poor  bus  utilization. 

3.3*2  Increasing  Information  Density  Within  a Message  Block 

One  approach  to  circumventing  this  problem  is  to  organize  the 
information  flow  between  the  bus  controller  and  the  equipments 
serviced  by  the  bus  so  that  the  block  of  Data  Words — rather  than 
the  single  DW  terminating  the  block--contains  useful  information  for 
the  recipient.  While  such  a technique  is  self-evident  and  has  been 
automatically  adopted  in  some  bus  configurations,  difficulties  arise 
which  tend  to  offset  the  anticipated  increase  in  information  density 
within  a message  block.  These  problems  stem  from  the  flexibility  of 
information  transfer  which  the  bus  is  intended  to  promote;  namely,  a 
range  of  rates  at  which  the  equipment  parameters  can  be  sampled,  and 
multiple  users  of  subsets  of  the  set  of  DWs  generated  by  a 
subsystem. 

Consider  a specific  example.  In  allocating  the  storage  at  a 
remote  terminal  amongst  the  equipments  being  serviced,  it  would  seem 
r easonable--as  a first  pass--to  allocate  a single  subaddress  to  a 
navigational  subsystem,  say;  the  intent  being  that  all  the  Data 
Words  generated  by  that  unit  would  be  stored  in  the  32  locations 
associated  with  that  subaddress,  and  updated  in  real  time  as  the 
requirement  demands.  Due  to  the  intrinsic  physical  characteristics 
of  the  various  parameters  which  the  Data  Words  represent,  their 
bandwidth--and  hence  their  update  rates--will  differ  one  from 
another.  For  example,  the  control  information  defining  a band 
switching  operation  will  have  different  response  time 
characteristics  from  range  and  bearing  data,  and  hence  will  not 
require  sampling  at  the  same  rate  by  the  user.  However,  it  has 
already  been  shown  that  selective  interrogation  of  DWs  within  a 
subaddress  can  lead  to  inefficient  use  of  the  bus. 
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If  for  convenience  of  implementation  it  is  decided  that  all 
parameters  of  the  unit  should  be  transferred  to  the  user  at  the 
maximum  rate,  then  there  will  be  an  effective  reduction  in  the 
available  information  capacity  of  the  line.  The  significance  of  the 
reduction  is  a function  of  the  particular  equipment,  number  of 
users,  etc.,  and  cannot  be  concisely  generalized.  However,  to 
illustrate  the  effect,  consider  an  equipment  which  has  four 
parameters  requiring  sampling  by  a user  at  8,  4,  2,  and  1 times  per 
second,  respectively.  If  each  parameter  requires  a separate  DW, 
then  the  message  transferring  the  information  to  the  user  will 
contain  a block  of  four  Data  Words,  and  it  will  be  sent  eight  times 
per  second.  The  redundancy  of  such  a transfer  would  be 
approximately  50  percent — a sharp  reduction  of  the  capacity 
presented  in  Figure  4. 

3*3*3  Allocation  of  Multiple  Subaddresses  to  a Subsystem 

To  avoid  the  potential  problem  outlined  above,  it  has  been 
suggested  that  the  parameters  output  by  a subsystem  be  grouped 
according  to  sampling  rate,  and  each  subdivision  be  allocated  a 
separate  subaddress,  see  Figure  9.  Each  subaddress  could  then  be 
sampled  at  its  appropriate  rate  and  all  words  in  the  message  block 
would  be  non-redundant  information.  This  would  overcome  the  problem 
of  redundancy  if  the  word  transfers  for  a given  subsystem  were 
between  a unique  source-sink  pair,  or  alternatively  between  several 
source-pairs  with  the  same  information  transfer  requirements. 
However,  in  general,  this  will  not  be  the  case;  various  "sink” 
subsystems  will  likely  use  different  subsets  of  the  data/parameters 
generated  by  a "source"  subsystem,  see  Figure  10. 

The  discussion  above  relating  to  multiple  sampling  rates  is 
equally  applicable  to  the  problem  of  multiple  users.  Analogous  to 
the  flow  of  redundant  information  due  to  oversampling,  is  the 
transfer  to  a user  of  all  the  parameters  generated  by  a source 
subsystem,  rather  than  only  the  subset  which  it  needs.  The  solution 
is  also  similar;  the  grouping  of  the  subsystem's  output  into  subsets 
used  by  unique  source/sink  pairs,  and  then  the  allocation  of  a 
subaddress  to  each  subset.  However,  it  should  be  noted  that  the 
number  of  locations  occupied  at  the  remote  terminal  may  now  be 
increased  due  to  the  need  for  multiple  copies  of  the  Data  Words 
required  by  more  than  one  user. 

A conceptual  allocation  of  storage  at  a remote  terminal  unit 
for  an  equipment  producing  parameters  of  various  sampling  rates, 
working  with  a number  of  users  requiring  only  subsets  of  the  data 
items,  is  shown  in  Figure  11.  It  can  be  seen  that  in  attempting  to 
reduce  information  redundancy  on  the  bus  there  has  been  profligate 
usage  of  the  31  subaddresses  available  to  each  remote  terminal. 

Once  again,  the  significance  of  this  depends  on  several  factors. 
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ORGANIZATION  OF  OUTPUT  FROM  A GIVEN  FUNCTION  BY  SEPARATE 
SUBADDRESSES  FOR  EACH  SAMPLING  RATE 


DATA  WORDS : 
SAMPLE  RATE  I 
USER  l 
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10  CONCEPTUAL  SUBDIVISION  OF  OUTPUT  INFORMATION  FROM 
A SOURCE  SUBSYSTEM  SERVICED  BY  A REMOTE  TERMINAL 


SUBADDRESS  CONTAINS  EACH  SUBADDRESS  CONTAINS  DATA  WORDS  FROM 

DATA  WORDS  SAMPLED  AT  A GIVEN  FUNCTION  SAMPLED  THE  SAME  RATE  BY  A 

DIFFERENT  RATES  FOR  GIVEN  USER 
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SEPARATE  SUBADDRESSES  FOR  EACH  SAMPLING  RATE/ USER  PAIR 


For  example,  if  the  remote  terminal  in  question  is  intended  to 
service  a concentration  of  equipment  located  in  an  equipment  bay, 
then  it  is  likely  that  there  will  be  a dearth  of  subaddresses,  and 
the  allocation  of  several  to  a subsystem  could  result  in  the  use  of 
additional  remote  terminals,  or  even  require  an  increase  in  the 
number  of  buses  used.  If,  on  the  other  hand,  the  RT  is  servicing 
few  subsystems,  the  need  for  a multiplicity  of  subaddresses  for  each 
may  not  be  a problem. 

Another  point  is  that  the  original  intent  of  increasing  the 
information  density  in  a block  of  words  has  led  to  a decrease  in  the 
number  of  Data  Words  per  message  from  that  which  might  have  been 
anticipated  when  considering  the  total  DW  output  of  the  equipment. 
Thus,  the  goal  of  increasing  the  effective  information  capacity  of 
the  bus  by  increasing  the  information  density  of  a block  of  Data 
Words  is  thwarted  by  the  lower  information  capacity  resulting  from 
the  use  of  shorter  messages. 

3.3*^  Another  Attempt  to  Increase  Message  Length 

It  was  originally  suggested  that  a given  subsystem  serviced  by 
the  bus  should  be  allocated  a single  subaddress  for  data  storage. 

The  potential  inefficiency  of  this  approach--in  terms  of  available 
information  capacity  of  the  bus--leads  to  the  suggestion  that 
several  subaddresses  per  subsystem  would  be  preferable.  This  in 
turn  indicated  potential  inefficiencies  arising  from  the  shorter 
message  length  that  would  result,  and  a possible  shortage  of 
subaddresses,  requiring  an  increase  in  the  number  of  remote 
terminals  required.  To  offset  both  of  these  problems,  it  has  been 
proposed  that  the  unique  subsystem — subaddress(es) — combinations  be 
abandoned.  The  idea  would  be  to  maintain  the  sample  rate  and  subset 
subdivisions  outlined  above,  but  to  pack  information  of  the  same 
type  from  other  equipments  into  the  common  subaddress.  The 
configuration  would  be  similar  to  that  shown  in  Figure  11  but 
without  the  constraint  of  all  Data  Words  being  generated  by  the  same 
source  function.  The  packing  could  be  by  both  Data  Words  in  message 
block  and  by  bits  in  a Data  Word,  see  Figures  12  and  13*  Such  an 
approach  could  possibly  result  in  more  efficient  bus  usage  by 
eliminating,  or  reducing,  the  transfer  of  redundant  information, 
while  permitting  the  use  of  longer  messages — containing  information 
from  several  subsystems  serviced  by  the  same  remote  terminal. 

The  primary  disadvantage  of  this  technique  cannot  readily  be 
expressed  quantitatively;  however,  it  would  significantly  impact  the 
buses'  flexibility.  One  of  the  guiding  tenets  throughout  the  design 
of  the  processing  associated  with  the  transfer  of  information 
between  units  serviced  by  the  bus  has  been  to  partition  the  data 
flow  so  that  changes  in  the  information  requirements  on  one 
source/sink  pair  do  not  impact  other  units  on  the  bus.  The  purpose 


30 


IA  -4  6,3  12 


< 


2 

cr 

UJ 


LlI 

F- 

o 

2 

UJ 

q: 


o 

>- 

q: 

CO 

uj 

-J 

CO 

-j 

CO 

o 

UJ 

(r 

K 

>- 

o 

z 

o 

o 

< 

o 

QD 

CO 

z> 

3 

CO 

CD 

to 

co 

UJ 

o: 

q 

o 

< 

CD 


^ CNJ 
Q — 


* - 
Q — 


* 

O 


UJ 

CT 


cr 

Q 

UJ 

Q 

_J 

_j 

< 

o 

cr 

QD 

3 

F— 

CO 

z 

o 

* 

o 

-1 

CO 

< 

3 

Z 

CD 

— 

2 

O 

cr 

F— 

UJ 

F- 

co 

" 2 
o 00 

2 

uj  o 


CO 

Z> 

QD 

* 

o 

-J  H 
^ CNJ 

5 + 

2 w 

^ co  ^ 

UJ  WUJ 
K UJ 

cr 

w o o 
{- Q tr 
o<  f- 

2 CD  Z 

UJ  id  O 

(two 


> + 

O FO 


* FO 
Q IO 


3t  CNJ 
O PQ 


* - 
o fO 


* 

CO 


* 

o 


J t 

O FO 


> 2 

Q FO 


O FO 


* - 
Q FO 


* 

Q 


J <NJ 
Q — 


* “ 

O ~ 


* 

CO 


* 

o 


L 


J 


o 

2 cr 
£ o o 
£ 

Q O 
Z <o  * 
< 3 

2 h < 

2 < F- 
O *-  < 
O CO  O 

* * * 

O GO  O 


~ 

CNJ 

ro 

UJ 

UJ 

UJ 

UJ 

o 

CD 

CD 

o « 

< 

< 

< 

UJ  < 

CO 

CO 

CO 

*:  co 

CO 

CO 

CO 

o to 

UJ 

UJ 

UJ 

< w 

2 

2 

2 

Q-  2 

31 


Figure  12  MESSAGE  PACKING 
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Figure  13  WORD  PACKING 


of  this  is  to  ensure  that  the  bus  control  software  can  readily  be 
adapted  to  changes  in  the  equipment  complement  being  serviced, 
without  extensive  modifications  to  the  processing  involving  the  data 
flow  to  other  source/sink  pairs  in  the  avionics  suite.  The  storage 
of  information  from  several  subsystems  at  a common  subaddress--or 
set  of  subaddresses--would  jeopardize  this  goal  of  separability.  In 
general,  a processing  routine  used  to  pack/unpack  a message  block  or 
Data  Word,  and  to  collect/distribute  the  information  it  contains  is 
dependent  on  the  source-sink  pairs  involved.  It  is  conceivable  that 
some  measure  of  standardization  in  this  area  might  formalize  the 
changes  in  processing  incurred  by  the  inclusion,  or  removal,  of 
equipment  in  the  avionics  suite.  However,  until  such  procedures  are 
established,  it  is  desirable  in  the  interest  of  flexibility,  i.e.  in 
the  ability  to  adapt  to  changes  in  an  equipment  complex  with  minimum 
modification  to  the  collection  and  distribution  segment  of  the  bus 
control  software,  to  organize  the  storage  at  the  remote  terminal  to 
permit  easy  separability  of  data  flow  between  the  source-sink  pairs. 

3.3*5  General  Comment  on  Storage  Organization  at  a Remote 

Terminal 


The  presentation  given  above  is  relatively  simplistic,  and 
various  organizations  of  particular  classes  of  data,  for  example, 
parameters  of  different  bandwidths,  can  partially  offset  some  of  the 
inefficiencies  outlined  above.  However,  it  is  not  the  intention  to 
exhaustively  discuss  these  particular  aspects  of  the  data  transfer 
between  units,  but  rather  to  indicate  that  the  available  information 
capacity  of  the  bus  as  graphed  in  Figure  4 is  an  upper  bound  that 
cannot  readily  be  approached  without  considerable  detailed  design 
effort. 

If  efficient  usage  of  the  bus  capacity  is  of  academic 
interest — due  to  under  utilization  by  the  equipment  complex  which 
the  bus  services--then  the  storage  organization  to  be  used  can  be 
selected  by  criteria  other  than  that  of  available  information 
capacity.  However,  if  information  transfer  capacity  is  of 
significance,  then  a host  of  interacting  factors  involving  hardware, 
software,  and  operational  factors  must  be  considered.  Any  practical 
attempt  to  quantitatively  assess  the  sensitivity  of  the  information 
capacity  of  the  bus  to  a range  of  permutations  of  these  conditions 
would  necessitate  the  development  of  a relatively  complex 
simulation . 

3 • 4 Temporal  Aspects  of  Signal  Information  Transfer  by  an  Avionics 

Bus 


The  following  section  is  included  not  because  of  any  particular 
constraint  imposed  by  MIL-STD-1553  (USAF),  but  rather  because  little 
is  said  on  the  time  related  aspects  of  information  transfer  even 
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though  they  can  have  significant  impact  on  bus  standardization  and 
design-  The  presentation  of  the  material  is  in  the  form  of  an 
annotated  listing  of  some  of  the  different  types  of  information — in 
regard  to  their  temporal  characteristics--that  might  be  placed  on 
the  bus,  with  some  discussion,  where  appropriate,  as  to  how  those 
factors  might  influence  the  system  design. 

In  considering  some  of  the  general  time-related  characteristics 
of  information  flow  on  the  bus,  it  is  appropriate  to  start  with  the 
physical  event,  or  process,  that  the  data  describes.  Of  the  set  of 
descriptors  that  define  a phenomenon,  the  two  that  are  considered 
here  are  the  time  of  occurrence  of  an  event — its  epoch — and  a 
measure  of  its  dynamic  characteristics — its  bandwidth.  No  attempt 
will  be  made  to  discuss  the  very  real  subtleties  in  these  concepts, 
and  an  heuristic  discussion  based  on  a general  understanding  of  what 
these  parameters  describe  should  be  sufficient  for  the  present 
purpose.  In  this  context  then,  the  function  of  the  information 
distribution  system  is  to  transfer  data  between  a source-sink  pair 
in  a manner  that  is  compatible  with  the  temporal  characteristics  of 
the  source  and/or  the  needs  of  the  user.  The  performance  of  the 
transfer  network  cannot  enhance  the  intrinsic  properties  of  the 
source  process;  for  example,  sampling  its  output  at  above  the 
Nyquist  rate  will  not  increase  its  bandwidth.  On  the  other  hand, 
the  distribution  system  can  distort  the  available  information;  an 
unknown  delay — fixed  or  variable — can  cause  uncertainty  in  an  epoch; 
undersampling  can  misrepresent  the  dynamic  characteristics. 

However,  there  is  nothing  sacrosanct  about  the  characteristics  of 
the  source  process.  If  a distorted  representation  is  adequate  for 
the  purpose  of  the  user,  then  it  is  pointless  to  load  the  bus  with 
the  additional  data  resulting  from  sampling  to  match  an 
unnecessarily  large  bandwidth.  The  crucial  factor  is  that  the 
standard  bus  is  intended  to  be  a tool  for  the  system  designer;  while 
a wide  range  of  capability  is  desirable,  it  is  equally  important 
that  all  pertinent  aspects  of  its  performance  be  defined  so  that  a 
user  can  employ  the  distribution  network  for  his  own  ends.  The 
following  subsections  differentiate  between  some  of  these  uses,  and 
indicate  their  relationship  to  bus  characteristics. 

3.4.1  Control  Information;  Human  in  Loop 

One  class  of  information  that  is  suitable  for  transmission  on 
the  bus  is  the  control  signals  initiated  by  an  operator's 
manipulation  of  switches  and/or  dials.  The  acceptance  of  human 
response  times  within  the  loop  ensures  that  the  bandwidth  of  the 
process  is  relatively  narrow  (~1  Hz),  and  can  readily  be  handled  by 
the  signal  detection  and  distribution  system  operating  at  low 
sampling/message  rates  for  each  control  function.  Analyses  of 
typical  avionics  suites  have  indicated  that  this  type  of  data 
comprises  a large  proportion  of  the  information  flowing  between  the 
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equipments,  and  thus  gives  credence  to  the  suitability  of  a bus  as 
the  communication  medium. 

3.4.2  Control  Information;  No  Human  in  Loop 

When  the  control  loop  does  not  contain  a man-activated 
operation,  more  care  is  necessary  to  determine  what  temporal 
characteristics  of  the  source  must  be  reproduced.  For  example,  a 
Mach  2 aircraft  moves  approximately  2000  fps,  thus  some  functions 
which  are  highly  range  sensitive  might  require  sampling  at  such  a 
high  rate  that  they  absorb  too  great  a fraction  of  the  bus  capacity. 
Even  if  the  system  designer  is  prepared  to  sample  at  the  required 
rate,  and  thus  preserve  the  dynamic  description  of  the  source,  the 
"real-time"  nature  of  the  data  must  be  maintained.  For  example, 
delaying  the  data  by  buffering  the  message  stream  in  a first-in 
first-out  memory  prior  to  placing  the  messages  on  the  line,  might  be 
a desirable  and  acceptable  design  approach  when  handling  data  that 
can  tolerate  the  delay;  whereas  in  other  cases  it  might  render  the 
data  worthless.  Fortunately,  the  number  of  functions  in  which  the 
foregoing  considerations  are  significant  appears  to  be  small. 
However,  the  standard  bus  should  be  sufficiently  well  defined  that  a 
system  designer  has  enough  information  to  make  assessment  in  any 
particular  case. 

3.4.3  Explicit  and  Implicit  Time  Tagging 

In  the  previous  sections  the  temporal  characteristics  of  the 
output  from  the  source  were  of  varying  degrees  of  importance,  but  in 
neither  case  was  the  actual  time--in  contradistinction  to  the 
occurrence--of  an  event  of  significance.  However  in  some  cases,  for 
example  when  navigational  data  from  diverse  sources  are  being 
combined,  it  may  be  necessary  to  associate  time  labels  with  the 
various  events.  It  should  be  stressed  that  the  epoch  which  is  being 
considered  is  that  of  an  event  of  the  source  process;  not  the  time 
at  which  its  output  is  received  by  the  user,  nor  processed  by  the 
controller,  nor  any  one  of  the  many  other  phases  of  its  existence 
before  its  identity  is  lost  on  being  merged  with  other  data.  The 
constraints  on  the  bus  design  arising  from  the  need  to  handle  "epoch 
sensitive"  data  can  range  from  negligible  to  significant,  depending 
on  the  accuracy  required,  nature  of  the  source  process,  and  many 
other  factors. 


3.4.3. 1 Explicit  Time  Tagging.  While  an  obvious  approach  to 
handling  epoch  sensitive  data  is  to  attach  a time  label  to  the 
source  output,  the  method  of  implementation  is  less  self-evident. 

For  example,  should  the  source  subsystem  itself  be  required  to 
supply  the  tag,  or  should  it  be  a function  of  the  sampling  operation 
within  the  remote  terminal?  In  both  cases  the  load  on  the  bus  will 
be  increased  for  this  class  of  information;  however,  the  impact  on 
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the  terminal  design  would  be  quite  different.  Again,  what  are  the 
relative  constraints  on  time  tags  originating  at  different  remote 
terminals?  At  present  the  bus  controller  and  the  remote  terminals 
operate  asynchronously,  and  no  explicit  mechanism  is  included  for 
the  correlation  of  events  at  various  locations;  will  this  suffice 
for  future  applications  projected  for  a standard  bus? 

3. 4. 3. 2 Implicit  Time  Tagging.  Another  class  of  data  that  may 
constrain  the  bus  design  is  that  in  which  a constant  interval 
between  samples  is  assumed  by  the  user.  That  is,  if  the  initiation 
of  the  sequence  of  samples  is  at  time  t q,  the  implicit  time  tags  are 
t0  + At,  t0+  2At,...etc.  where  At  is  the  nominal  sampling  interval. 
The  present  standard  permits  bus  designs  which  could  impose  a jitter 
on  the  data  sent  to  the  user;  whether  this  is  significant  would 
depend  on  the  specifics  of  the  case.  If  some  form  of  correction  is 
necessary,  explicit  time  tags  can  be  associated  with  the  nominally 
periodic  samples;  however,  the  additional  data  processing  involved 
in  the  use  of  non-uniform  data  can  be  considerable. 

3.4.4  Data  for  Post-Flight  Analysis 

If  both  time  of  occurrence  and  dynamic  representation  of  the 
source  output  is  of  importance,  but  the  information  is  not  required 
for  real-time  operation,  then  the  specifications  for  the  network  are 
less  demanding  than  those  outlined  in  the  previous  sections.  An 
example  of  such  a function  is  the  recording  of  data  for  post-flight 
analysis,  such  as  might  be  involved  in  a reconnaissance  mission.  An 
accurate  reconstruction  of  the  flight  path  of  the  vehicle  may 
require  precise  epoch  and  relatively  high  bandwidth  data;  however, 
in  the  course  of  its  transfer  from  source  to  sink,  a substantial 
known  delay  could  be  tolerated  without  degrading  the  quality  of  the 
reconstituted  track. 

3.4.5  Summary  on  Temporal  Aspects  of  Siftnal  Transfer  by  an 

Avionics  Bus 


The  foregoing  sections  provide  only  a superficial  treatment  of 
some  of  the  temporal  problems  that  arise  when  signals  are 
transferred  between  source-sink  pairs  on  an  avionics  bus.  Other 
classes  of  data  could  have  been  included;  some  of  the  problems 
anticipated  could  be  shown  to  be  non-existent  under  some  conditions 
and  severe  under  different  circumstances,  and  so  on.  However,  as 
was  stated  in  the  introduction,  the  aim  of  Section  3*4  is  not  to 
provide  an  exhaustive  treatment  of  the  subject,  but  rather  to  alert 
the  system  designer  to  an  aspect  of  bus  design  that  is  only  briefly 
touched  upon  in  the  military  standard,  and  yet  can  have  considerable 
bearing  on  the  compatibility  of  "standard  bus”  designs. 
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4.0  SUMMARY  AND  CONCLUSIONS 


Since  MIL-STD-1553  (USAF),  defining  a preferred  configuration 
for  a TDM  avionics  bus,  was  issued  in  August  1973,  MITRE  has  been 
critically  evaluating  its  content.  Part  of  the  task  has  been  the 
development  of  an  experimental  bus  which  embodies  most  of  the 
standard's  requirements.  In  the  course  of  engineering  the  software 
for  the  message  control  function,  several  factors  emerged  which  were 
not  immediately  apparent  on  first  reading  the  standard.  In  some 
areas  joint  consideration  of  requirements  gave  rise  to  severe 
constraints  on  the  bus  network.  In  other  instances  there  was 
sufficient  ambiguity  to  warrant  the  belief  that  buses  designed  in 
accordance  with  the  standard  could  have  different  performance 
capabilities  in  areas  pertinent  to  the  internal  transfer  of  data, 
and  moreover,  be  incompatible  for  the  interchange  of  data  one  with 
another. 

Four  main  topics  have  been  discussed: 

• Bus  capacity.  The  requirements  on  the  message  formats  and 
bus  protocol  that  are  contained  in  the  standard  have  been 
combined  to  determine  an  upper  bound  on  the  capacity  of  the  bus 
available  for  moving  data  between  source-sink  pairs.  The 
available  capacity  is  shown  to  be  a strong  function  of  the 
number  of  Data  Words  in  a message,  and  is  at  best  less  than  7 5% 
of  the  nominal  bus  capacity. 

• Time  constraint  on  message  handling.  The  implicit 
requirement  on  the  bus  capacity,  and  the  explicit  definition  of 
the  message  formats,  have  been  combined  to  give  an  estimate  of 
the  minimum  time  available  for  the  bus  controller  to  handle 
successive  messages  when  the  bus  is  being  operated  at  100 
percent  duty  cycle.  A typical  general  purpose  airborne  computer 
cannot  support  the  task,  and  a special  purpose  processor  of 
considerable  sophistication  is  necessary  if  the  maximum  message 
rate  permitted  by  the  standard  is  to  be  realized. 

• Subaddresses  and  Data  Word  accessibility.  The  standard 
format  of  the  Command  Word  defines  the  addressing  mechanism 
that  must  be  used  by  the  bus  controller  to  obtain  information 
from  a remote  terminal.  Data  Words  must  be  accessed  by  blocks 
rather  than  separately.  Consequences  of  this  have  been 
investigated  and  shown  to  have  the  potential  of  reducing  the 
useful  bus  capacity  significantly  below  the  upper  bounds 
dictated  by  overhead  considerations. 

• Temporal  considerations  of  information  transfer  on  the 
avionics  bus.  Since  all  data  transferred  on  the  bus  is 
sensitive,  to  some  degree,  to  misrepresentation  of  its  epoch 


37 


and  bandwidth,  some  consideration  was  given  to  this  aspect  of 
bus  design.  Although  the  investigation  was  relatively  cursory, 
it  is  apparent  that  because  the  standard  gives  such  superficial 
guidance  in  this  area  there  is  a very  real  possibility  that 
"standard"  buses  would  differ  significantly  in  their  ability  to 
transfer  the  temporal  characteristics  of  a source  process  to 
the  user. 

The  generation  of  MIL-STD-1553  (USAF)  was  a major  step  forward 
in  standardizing  the  application  of  TDM  buses  to  aircraft.  However, 
experience  is  showing  that  uncertainty  regarding  its  intent  still 
exists,  and  must  be  removed  before  the  goal  of  meaningful 
standardization  can  be  achieved. 
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APPENDIX  I 


A.O  CALCULATION  OF  UPPER  BOUND  ON  INFORMATION  CAPACITY  OF  A 
STANDARD  BUS 

The  message  and  word  formats,  together  with  the  bus  protocol, 
defined  in  MIL-STD-1553  (USAF),  result  in  some  fraction  of  the 
nominal  capacity  of  the  bus  being  absorbed  in  the  transfer  of 
"overhead"  data.  Curves  quantifying  this  effect  are  given  in 
Figures  4 and  5 in  the  body  of  this  report.  The  following 
calculations  are  given  to  permit  the  reader  to  confirm  his 
understanding  of  the  terms  used. 

A. 1 Controller/Remote  Terminal  Transfers 


The  word  and  message  formats  of  the  Controller/Remote  terminal 
transfers  are  given  in  Figures  2 and  3*  For  an  N Data  Word 
transfer,  the  total  bit  requirements  are: 


Information  bits: 

16N 

Overhead  bits: 

2 x 20 

4N 

"No  signal"  bits: 

tsep 

tsep 

Fractional  information 

capacity 

Command  Word  and  Status  Word 
Sync  and  Parity  on  N Data  Words 

Intermessage  gap 
Intercomponent  gap 


16N 

(N+2)  20  + 2t 

sep 


CU/RT  and  RT/CU 


Fractional  overhead  capacity  is 


•« 


4N  + 40 
(N+2)  20  + 2t 

sep 

Fractional  "no  signal"  capacity  is 
2t 


sep 

(N+2)  20  + 2t 

sep 


CU/RT  and  RT/CU 


CU/RT  and  RT/CU 
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A.  2 Remote  Terminal  to  Remote  Terminal  Transfers 


The  word  and  message  formats  of  the  RT/RT  transfers  are  given 


in  Figures  2 and  3* 
requirements  are: 

For  an  N Data 

Word  transfer,  the 

total  bit 

Information  bits: 

16N 

Overhead  bits: 

4 x 20 
4N 

Two  Command  Words  and  2 Status 
Words 

Sync  and  parity  on  N Data  Words 

"No  signal"  bits: 

t sep 

2tsep 

Intermessage  gap 
Intercomponent  gap 

Fractional  information  capacity  is 


16N 

20  (N+4)  + 3t 

sep 


RT/RT 


Fractional  overhead  capacity  is 


4N  + 80 
20  (N+4)  + 3t 

sep 


RT/RT 


Fractional  "no  signal"  capacity  is 


3t 


'sep 
20  (N+4)  + 3t 


sep 


RT/RT 


The  relationships  given  in  Sections  A.1  and  A. 2 are  graphed  in 

Figure  4 for — the  number  of  Data  Words  in  a message,  N — ranging 

between  1 and  32,  and  for  t =2  and  5 microseconds. 

’ sep 

A . 3 Upper  Bound  on  Message  Rate  on  a Standard  Bus 

The  upper  bound  on  the  message  rate  on  a standard  bus  is 
obtained  directly  from  the  total  number  of.  bits  in  a message 
sequence — see  Sections  A.1  and  A. 2 above. 

Maximum  number  of  message  sequences  per  second  is: 


[20  (N+2)  + 2taeJ-' 

CU/RT  and  RT/CU 

[20  (N+4)  + 3tsep]'1 

RT/RT 

* 
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These  relationships  are  graphed  in  Figure  5 for  N between  1 and  32, 
and  for  tsep  = 2 and  5 microseconds. 
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